1. Field of Art
This application relates generally to the field of information retrieval and, in particular, to multi-prefix, multi-tier, dynamic menu and related interactive search techniques that facilitate the retrieval of information within a mobile communications environment, including the leveraging of collaborative “cloud” services that enable the maintenance and sharing of such information.
2. Description of Related Art
In the last few years, web-enabled mobile telephones have become enormously popular. More web-enabled mobile phones ship each year than do desktop and notebook computers combined. Such mobile phones are similar to desktop and mobile computers in that they offer display screens, a keyboard, and, sometimes, a pointing device. However, because of portability requirements, the capabilities of the displays, keyboards, and pointers on mobile phones are significantly reduced. Displays are relatively small with little area to display content as well as menus, toolbars, and other navigation and status information. The keyboards are often telephone keypads or thumb keyboards. The pointer, when provided, is often a scroll wheel or joystick that can be used to indicate a direction of movement or pressed to indicate a click. Sometimes, the pointer is simply a set of arrow keys on the keyboard. Furthermore, because of speed and latency issues, navigation among web pages is typically much slower on mobile phones than on desktop and notebook computers.
The human interface limitations of mobile phones, combined with slower navigation, significantly constrain a user's ability to interact with web pages. Additionally, Hypertext Markup Language (HTML) forms are difficult to use on mobile phones due to data input and related limitations. These difficulties arise in many ways. For example, the mobile keyboard and pointer are less effective than their counterparts on desktop and personal computers.
Keyboards are less effective because their small form factor makes it more difficult to type characters. In some case, the keyboard is smaller and has fewer keys. The smaller keyboards usually require thumbing: typing with one's thumbs rather than using ten fingers. The reduction in keys makes it more difficult to key in digits and special characters. Some keyboards are telephone dial pads with multiple letters on each key. Various technologies, including triple tap (pressing the same key until the desired letter appears) and predictive text, help to improve the effectiveness of such keyboards, but the effectiveness is still far below that of a full-size keyboard.
The pointer is also less effective. HTML forms often contain multiple input fields and the pointer is used to navigate among them. Pointers on mobile phones, when available, are less effective than pointers or mice used with desktop computers for navigating among input fields, as well as hyperlinks and other screen objects. For example, tabbing between fields using a full-size keyboard enables the field for typing when it has received focus. On a mobile phone, the tabbing is typically done via a directional pad and the field often has to subsequently be selected to be enabled for typing. Additionally, on desktop computers, mice can be used to move from one field to another without having to move through the fields in between. On mobile phones, moving from one field to another is typically done sequentially from one field to the next, without the ability to skip any fields along the way.
However, some web-enabled mobile phones have touchscreens that provide for direct interaction with objects on the display screen. For example, users can touch a screen object directly with their fingertip or a stylus, rather than indirectly navigate to that object via a pointing device. Yet, even this “improved” user interface technique raises usability issues, as the distinction between “selecting” and “activating” an object becomes blurred. Potential solutions for distinguishing the two include providing an icon or other visible identifier on a portion of the object, or discerning the number of times a user clicks or taps it, or the amount of time a user “presses down” on the object.
In any event, the ability to select an object without also activating it becomes particularly important in systems that provide alternative functionality specific to a particular object. For example, when a user activates an HTML hyperlink in a web browser, the program typically navigates to a new web page corresponding to the URL embedded within that hyperlink object. The user, however, might want to examine the URL before making the decision to activate the hyperlink.
A common mechanism for offering a user alternative functionality specific to a selected object is a “context menu.” Context menus provide a user with one or more alternative functions available within a particular “context” or state of a program or device, such as the selection of a particular object. Context menu items can change dynamically as the context changes, as different objects are selected and as a program enters a different state.
In a mobile communications environment, however, providing context menus with which users can quickly interact is easier said than done. The state of an information retrieval system can change frequently, for example, as new search results are received from remote servers (or as information becomes known to the system, such as the time of day or a user's location as indicated by a mobile phone's GPS equipment). In addition to the problem noted above of distinguishing the selection from the activation of an object, other constraints include processing speed and memory limitations on mobile devices, as well as bandwidth and latency limitations inherent in mobile communications networks. These constraints, coupled with the many different types of information that can be retrieved from remote web sites, for example, make it even more difficult to provide context menu items that are customized to particular objects or categories of objects.
In contrast to the “random” full-text searches users often perform on desktop computers in home and office environments (in which multiple iterative searches and analyses of resulting web pages can be completed relatively quickly due to greater bandwidth and local computing resources), users in a mobile communications environment often perform more “targeted” searches for lists, schedules and other information the existence and perhaps even the location of which is often known in advance. Such information must nevertheless be retrieved relatively quickly in order to be useful. For example, common mobile searches include requests for stock quotes, sports scores, movie times and nearby restaurants or coffee shops, to name a few.
Targeted searches are less amenable to the random keyword search techniques commonly employed on existing desktop and mobile devices, in which users enter complete keywords and navigate through results and web pages across a large domain of web sites. Mobile devices, in particular, are in need of solutions in which targeted information can be found relatively quickly with minimal user interaction. Such solutions ideally would still afford users access to both the breadth of a large domain of information (such as the web with its diverse collection of web sites, or a large enterprise database) and the depth of any particular “channel” or information category (which may lend itself to unique functionality, whether within or across one or more web sites or databases).
Some mobile devices support applications that have been customized for highly targeted information retrieval, such as the “Pocket Express” application from Handmark Inc. (http://express.handmark.com/) which provides discrete modules for retrieving news, stock quotes, sports scores and various other specific types of information. Though useful for rapid retrieval of certain specific data, the domain of available information is inherently very limited, in part because each desired category of information requires its own custom module. Such an approach is not very scalable, given the vast array of information channels available via the web. Moreover, without a generic mechanism to locate information by searching within a particular module, users typically are limited to browsing or selecting items from within each module's predefined data structure. For example, users can browse news headlines and select one to retrieve the full story, but they cannot search for particular news stories, much less headlines.
Other products have attempted to reduce user interaction to perform targeted searches by enabling users to enter only word prefixes or word fragments, and providing results interactively as a user types characters. See, for example, a presentation at Google (http://video.google.com/videoplay?docid=7012265262667474421&q=type%3Agoogle+engEDU) in this area, or the “vTap” program from Veveo, Inc. (http://www.vtap.com), as well as Veveo's various published patent applications, including both PCT publications (WO/2007/062035) and US publications (2008011473, 20080086704, 20070255693, 20070130128, 20070088681, 200701754, 20070050337, 20070005563 and 20060101499). While providing an information retrieval mechanism that is more suitable to targeted searches, such approaches nevertheless lack a generic search mechanism that can be utilized to narrow a search request within a broad domain of information channels (to provide a more focused or targeted search), as well as provide additional functionality specific to particular channels.
Google, in a recent talk (http://jhtc.org/meeting.php?meeting=march08), discussed a “multi-tier” search technique in which a user first searches for a web site (for example, “Wikipedia”), the result of which contains not only a link to that site, but also a search box in which a “second-tier” search can be typed (thus saving the step of clicking on the link and then typing in the second-tier search). Other similar solutions include special search keywords that identify the second-tier site within the search query itself. Such solutions rely, however, on the differing search engines available across various second-tier sites, which not only force users to adapt to different search query formats, but also may provide inferior results when compared to more powerful search engines such as the one provided by Google. A more integrated multi-tier approach could avoid such anomalies by providing a consistent search mechanism among various tiers (within as well as across particular information channels), particularly one which also offered additional context-specific functionality.
As alluded to above, another search technique that has been employed to minimize user interaction (whether relating to single or multiple prefix queries, or full keywords) involves the display of “predictive text” while the user is entering a query. For example, a system might display multiple suggested phrases or keywords matching the keywords (or letters) typed thus far by the user, enabling the user to select from among these desired phrases or keywords without having to complete the full query. It should be noted, however, that such systems could reduce user interaction even further by displaying suggested query results (based upon implicit or explicit suggested query phrases or keywords), rather than merely displaying suggested queries.
Such an approach of providing “predictive results” could prove even more useful in the context of specific information domains or channels, not to mention the burgeoning field of interactive advertising in which targeted search results become opportunities (“ad inventory”) for displaying targeted ads (which can be further targeted via additional contextual information, such as a user's demographics, geographic location, viewing history, etc). Here too, a more integrated multi-tier approach could provide not only a consistent search mechanism among various tiers (within as well as across particular information channels), but also an improved targeted ad mechanism with increased ad inventory.
Apart from the need for a more integrated and consistent search mechanism, there is also a need for applications to obtain access to content in a usable form, as well as to enable users to share and retrieve such content. Whether hosted on the desktop, or in web-based or mobile environments, applications often need to provide mechanisms for users to enter or import content in a format that will facilitate the functionality provided by such applications. Typically, applications (or “apps”) maintain such content in their own proprietary internal format, perhaps allowing for the importing or exporting of data in one or more standard data formats.
If users need to update their content over time, apps must then provide a mechanism for users to access and update their content. Moreover, if designated groups of users require shared access to their content, apps must further provide a sharing mechanism, typically including user authentication and access control for particular activities (e.g., viewing and modifying all or certain portions of the content).
This need for shared content that users can update and access (preferably from multiple different devices, e.g., via a web browser or mobile app) has become quite common, and has spawned a trend frequently referred to as “cloud computing,” The content might be stored on a networked storage device or server computer (typically connected to the Internet), or on users' individual devices (networked hard disk, desktop or laptop computer, mobile phone, etc.) that are accessible to a remote app (or local “distributed” app) that synchronizes such content.
While many such collaborative “cloud” apps exist (e.g., “TeamSnap” at www.teamsnap.com for sharing team rosters, schedules, statistics and other related content among members of a sports team), each such app still must “reinvent the wheel” by implementing its own set of “cloud services”—e.g., collaborative features and user interfaces for maintaining and sharing content, including data acquisition, formatting, updating and presentation. As a result, there is a need for a mechanism to enable app developers to leverage existing cloud services, allowing them to focus their efforts on the “vertical” features specific to their particular content domain (e.g., team sports, trade shows, libraries, etc.), as opposed to the collaborative cloud services common across virtually all domains.
While some existing cloud apps have been designed as “platforms” that provide app developers with access (e.g., via a published API) to their cloud services and to user content, such platforms typically are designed to enable app developers to enhance the core capabilities of the cloud apps, rather than to repurpose user content to a particular “vertical” content domain.
For example, “social networks” such as Facebook were designed to facilitate the creation of user communities and the selective sharing of personal information among those communities. Because Facebook emphasizes the sharing of personal information, its focus is not on the creation and acquisition of structured content, much less “group content” compiled by one or more users. It is thus not surprising that most Facebook Apps developed on the Facebook platform leverage this core “sharing” functionality by providing shared access to external content (e.g., from other websites) and activities (e.g., games), rather than repurposing existing Facebook content.
While some Facebook Apps manipulate existing Facebook user content (e.g., to compile birthdays of a group of friends), they do not repurpose such content to a new content domain. It would be difficult, for example, for members of a sports team to maintain “team content” on Facebook, and for a Facebook App to access and repurpose such content to enable team members to share team rosters, statistics, etc.
Instead of providing all such functionality in a dedicated app, such as TeamSnap, it would be desirable to leverage existing cloud services to facilitate the maintenance and sharing of such “team content.” In this regard, various collaborative tools have implemented cloud services with respect to the acquisition and maintenance of general-purpose documents. Examples include “Google Docs” and “Google “Spreadsheets” (and various other apps from Google, Inc.), “Microsoft Office Live” from Microsoft Corp. and “Zoho Docs” from Zoho Corp. Other cloud apps are targeted at different types of documents, such as photo-sharing sites (e.g., “Flickr”), wikis (e.g., “Wikipedia”), etc.
The cloud services provided for a collaborative app such as “Google Docs” enable groups of users to maintain and share general-purpose documents. Users can create and edit such documents using many of the features found in standard word processors. Moreover, the Google Docs platform (via “Google APIs”) enables app developers to access user documents and leverage its cloud services.
Yet, as noted generally above, the primary purpose of this platform is to enhance the core capabilities provided by apps such as Google Docs (e.g., to provide additional functionality with respect to these general-purpose documents), rather than to repurpose user content to a particular “vertical” content domain. For example, an app might add a word-processing or other feature not found in Google Docs.
Perhaps due to the general-purpose nature of Google Docs documents, apps created for its platform tend to treat a user's Google Docs documents as “atomic” objects (independent of their content). For example, some apps generate filtered lists of documents, while others provide for remote storage or backup of documents.
Yet, because Google Docs allows for the maintenance of general-purpose documents that are not restricted to particular vertical applications, its appeal is universal, justifying the resources necessary to develop features and user interfaces that greatly simplify the collaborative process of creating, maintaining, presenting and sharing documents (much as social networks have done for the creation of user communities and the sharing of personal information generally).
A sports team could easily utilize Google Docs to facilitate the maintenance and sharing of its “team content,” as could groups of users across a vast array of content domains (such as trade show participants, a corporate sales force, users of a public library, etc.). Yet, the content maintained by Google Docs is only a set of general-purpose documents that users can view and edit. An external app would be necessary to provide additional “vertical” features that interpret and manipulate this content so as to enable users to interact with the content in a meaningful way in the context of a particular content domain. For example, an app could provide sports-related features akin to those found in TeamSnap (rosters, statistics, schedules, etc.), while leveraging Google Docs to provide the cloud services relating to the acquisition, maintenance and sharing of the content.
If one were to separate the acquisition, maintenance and sharing of the content (performed in a cloud app) from the interpretation and repurposing of the content to a particular content domain (performed in an external “vertical” app), then the tasks performed by users and app developers would be greatly simplified.
Existing technologies have not adequately addressed the problems intrinsic to targeted searching and the development of cloud apps, particularly given the unique demands of a mobile communications environment. Information must be retrieved more quickly, but with less user interaction, in light of the hardware, user interface, network bandwidth and latency limitations inherent in such an environment. In addition, a more integrated and scalable search mechanism is needed to allow users to request information from a broad domain of information channels and quickly locate desired information within one or more of those channels (including targeted ads), preferably with the availability of additional functionality that is tailored to those channels within the context of user requests and other available state information. Finally, mechanisms are needed for developing cloud applications, without sacrificing the consistency and simplicity offered by existing cloud services.